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(54) Titie: ANNOUNCED SESSION DESCRIPTION 
(57) Abstract 

The invention provides a method of announcing a description ^ 
of a media session, for example a multimedia conference. In one 
respect, the invention provides a modular method of announcing 
media sessions. This method comprises the steps of generating 
a first base module (410) having a first data structure comprising 
user oriented data relevant to the media session; generating at least 
one media module (421, 422, 423) having a second data structure 
comprising media oriented data necessary for a user to receive a 
respective media stream of the media session; providing a link 
between the first base module and the at least one media module; 
and. announcing the media session by making at least the first base 
module available to potential recipients of the media session, wherein 
the link between the first base module and the at lest one media 
module pemiits a user to access the at least one media module and 
subsequently receive the media stream. 
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ANNOUNCED SESSION DESCRIPTION 

The present invention relates to the announcement of media stream connections 
for a media session over a communications network. 
5 Multicast transmissions are becoming increasingly common on the Internet. In 

contrast to standard Internet Protocol (IP) point to point transmissions (unicast), IP 
multicast allows the simultaneous transmission of information to a group of recipients 
from a single source. Routing support for IP multicast transmissions is provided by the 
MBone (IP Multicast Backbone) which is a virtual network layered on top of the 
in Internet. 

IP multicast allows real-time communications over wide area IP networks and 
typical transmissions include video and audio conferencing, live multirhedia training, 
university lectures and transmission of live television programmes. 

A multicast transmission usually consists of a multimedia session made up of 
15 several individual media streams typically carrying video, audio, whiteboard or raw data. 
Some sessions are persistent, but the majority exist for a specific period of time, 
although need not be continuous. Multicast based transmissions on the MBone differ 
from unicast IP transmissions in that any user receiving the transmission can join the 
session (unless the transmission is encrypted) and to receive a transmission, a user 
20 need only know the appropriate transmission address and timing information. 

Prior to a multicast transmission an appropriate announcement containing a 
session description is made, usually at an IP group multi-cast address. Standard session 
descriptions are generated using a Session Description Protocol (SDP), as defined in the 
Internet Engineering Task Force's draft RFC 2327. SDP is a simple ASCII t-^xt based 
25 protocol that is used to describe real time multimedia sessions and their related 
scheduling information. SDP messages are wrapped in a carrier protocol, known as a 
Session Announcement Protocol (SAP), which, in addition to containing the necessary 
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,P 3.<.,essin. ana routing ,n,c,n,a.,on ,c, .ransn^ssion across ,He ,n«.net o, MBone, 
auows *e SOP n,essa.e .o be encvp.ed, s,gned o, con^presseC An anncunce-nen. can 
*.n .e sen, a, re,u,a, >n,erva.s to ,He anncunce„,en. .roup address. As an a«e.na.,ve 
.o SAP, a session n.av be announced bv p.ac*n. an SOP nnessa.e on a Wor,d Wide Web 

■ ^ , w nr as a unicast transmission inviting 

5 site (WWW) or by sending it to individuals by email or as a un c 

them to participate. 

An SOP n,essa.e conveys information about each media strean, in the n-u.ticast 
.uHin.edia session to a„ow tbe recipients to participate in the session. A tvpica, SOP 

,0 wii, be active, tbe component media streams o, tbe session and information required to 
panicipate in each madia stream .iP muiticas. address, port, media ,orma„. Tbe SOP 
message mav a.so inCude detaiis o, the session's bandwidth reouirements, an 
encryption .ey necessary to participate in a secure muiticast transmission usin. pubi.c 
..y encryption, contact information tor the organiser o, the muKicast session, and a 
,5 unioue Resource indicator ,UR,> pointing to a WWW or an intranet web site where 
further information on the session may be found, for e.ampie, bac..round infom,at,on 

relating to the conference. 

The ieve, of participation a user may ma.e in a session or stream depends on ,ts 
purpose, >n a muiticast teievision session, typicaiiy users wouid oniy be abie to recede 
,0 the session streams whiis. in a muiticast conference sess.on the communication wouid 
be bi-directionai with a centra, server .such as .roup address 120, receiving each 
participants transmissions and reiayin. them to the other participants. The ieve, o, 

session description or it may be inherent from the session description, for e.amp.e 

.5 When a r.ceive-on,y app,ica,ion is associated with a media stream type in t s,on 

description. 
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A common front end interface used by muiticast end users is known as Session 
Directory Rendezvous (SDR). This interface takes the received announcements, decodes 
the SDP message and displays the names of those sessions that are still current in a 
list. The end user may then select one of the listed announcements to view further 
technical and user-oriented details of the announced session. From the displayed 
information, the end user can then select to join individual streams of the session or to 
join the entire session. Once the streams to be joined are selected, SDR starts the 
necessary multicast-enabled multimedia application on the end user's computer, such 
as Vic and Vat, and passes the relevant stream information (a transport port address) 
from the announcement onto the application allowing the application to establish the 
link to the associated IP muiticast address and participate in the stream at transmission 
time. Having initiated the applications and passed the relevant transport port address 
SDR plays no further part in the session. 

Recent increased usage and demand for (multi)media sessions has highlighted a 
number of limitations in SDP. SDP limits session descriptions to defining a session 
having a single set of timings that apply to ail of the streams within it. A session in 
which a stream starts mid-way through the transmission cannot easily be described 
using SDP. The structure of a session description written in SDP must be a simple linear 
list of streams which may not reflect the intuitive structure of a complex session. SDP 
supports a limited and predefined set of applications which can receive the streams and 
a limited and predefined set of transport mechanisms (e.g. Simple layering, RTP and 
UDP). As guaranteed Quality of Service (QoS) is becoming more and more desirable to 
the consumer and the supplier, the need to define QoS policies for the entire session 
and individual streams in terms of required system resources, bandwidth requirements 
and supported applications also needs to be met. There may also be requirements on 
the prioritisation of streams and subsessions or more complicated rules about receiving 
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♦K«. «art of the suoDlier will be the need for charging 
streams. A further requirement on the part of the suppue 

* «.r,H „^fr for a multicast transmission to which 
facilities permitting the charging of an end user for 

..ev subscribe according to the QoS and types of streams received etc. There is little 
scope to include information about QoS policies or charging within the conventional 
structure of an SDP session description, or any metadata about the session. 

According to a first aspect of the present invention there is provided, a method 
o. announcing a description of a media session, comprising the steps of. 

generating a first base module having a first data structure comprising user 

oriented data relevant to the media session; 

„„e,at,ng at ,east one n,aaa n,od.>e having , second da,a structure coa.pris>n3 
„ed.a oriented data necessary .or a user to receive a respectWe media stream o, the 

media session; 

module; and, 

announcing the media session .v ma.ln, at .east the first .ase modu.e available 

to potential recipients o. the media session, 

^Herein the iin. between the .Irst base modu.e and the at least one media 

receive the media stream. 

The present invention provides a modular description system for a media session 
in Which session descriptions are constructed in a hierarchical manner providing a 
p,ura.ity o, levels o, in.ormation concerning the constituent parts o, the described 



20 



session. 



25 



A problem .aced with the current distribution o, announcements ,rom the single 
announcement group address is that there is a iimit to the size o. each announcement 
end the .reduency with which each can be sen, out. ,n the present Invention, it ,s 
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possible to provide a modular description system in which a distributed announcement 
contains links available to the end user to other portions of the announcement which 
have not been transmitted. 



5 Preferably, the method further comprises the steps of: generating a second base 

module, the second base module containing user orientated data relating to a sub- 
session of the media session; linking the second base module to the first base module; 
and, linking said at least one media module to the second base module. 

In preferred embodiments, the method further comprises the steps of: generating 
10 at least one options module having a third data structure comprising data relating to 
service level criteria required to participate in the media session; and, linking the or each 
options module to a respective base module. 

The data contained in the options module may relate to a quality of service 
policy to be used by the media session or a part thereof. Alternatively, the data 
15 contained in the options module may relate to a security system to be used by the 
media session or a part thereof. The data contained in the options module may further 
relate to a charging system to be used by the media session or a part thereof. 

in preferred embodiments, one or more media module(s) comprise data 
necessary for a user to receive a layered media stream of a respective media session; 
20 and said method further comprises the step of linking the or each media module to one 
or more respective options module{s) containing data relating to a layered mechanism of 
the respective layered media stream necessary for a party to participate in the layered 
media stream. 

The media session may be announced by transmitting all of the constituent modules of 
25 the session description. Alternatively, the media session may be announced by 
transmitting only some of the constituent modules of the session description, with the 
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..a-,n,n, n,odu,es o1 >on desc.p«c„ ...n. su.se,uent,v accessible bv a user 

usln, one or .,cre .n.s provided in .he ..oduies .rans^ined. The remair,in« -noduies o, 

,He session description .ay be heid on one or mo =rs and ,He one or n^ore iinKs to 

..e renrainin, n,odu,es are in tHe form o, UR, pointers. Moduies o, the session 
description contain iin.s to n,odu,es which are generated subsequent to the 
announcement. 

According to a second aspect o, the invention there is provided a con.puter 
readabie storage medium containing data de.ining at ieast a part o. a descrtption o, a 
media session, the session description comprising:- 

a first base moduie having a first data structure comprising user oriented data 

relevant to the media session; 

a, ieast one media moduie having a second data structure comprising media 
oriented data necessary for a user to receive a respective media stream o. the media 

session; 

5 a lini. between the first base moduie and the at ieast one media module; 

Another problem faced by prov.ders o, current Imultilmedia sessions and the 
aevelopers of the associated .multi.media app.ice«ons is the spread o, s.i.ls required to 
implement an application that can initiate and manage a real-time data connection over 
a communications networ. and perform the .multi.media functions the end user would 
20 expect, .or example, developers of multimedia applications reguire teams with s.ills ,n 
audio and video coding, network transport protocols, real time programming, user 
interface design and integration technigues. The session description of the present 
invention simplifies this process by allowing the necessary communication channels and 
media streams to be identified in the session description. This information is usSd by 
,5 generic middleware in the form o, a session control and communications manager to 
dynamically instantiate the respective streams and channels for the applications at run 
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time. 

Furthermore, until now the only way a QoS policy could be implemented was to 
process a session description to determine which streams of a session could or should 
be run and then to initialise the applications so they connect to the respective streams. 
5 This required the communications manager not only to know about the session 
requirements and available system resources but also the capabilities of each 
application. 

In a preferred example of the present invention the media modules of a session 
description are checked by the respective multimedia client application prior to QoS 
10 management, thereby reducing the workload of the communications manager, that is to 
say the respective client applications determine whether the media modules can be 
supported. Furthermore, applications need only request streams from the session 
control system associated with the client since the session control now handles 
centrally the creation and management of streams in real time. This aspect is also the 
15 subject of our co-pending UK patent application 9826157.1. 

The present invention simplifies application development and service provision. 
A further problem is that applications should be able to adapt to available network and 
host resources. This is particularly important for multi-party applications operating in 
heterogeneous environments where each party may have different resources available 
20 to them. Furthermore the nature of the heterogeneity may vary over the lifetime of the 
session, for example as network congestion varies or as the terminal resources are 
shared with other applications or other users. The present invention is able to use a 
QoS policy incorporated within the session description to prioritise the allocation of 
resources and to determine whether participation in the session is viable. 
' 25 A still further problem is that the application developer and service provider 

typically need to address security and charging requirements. The present invention 
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a„ows security and chargln. pCiCes ,0 be .ncorporated wi,«n ion deec.p«cn 

use witWn the session centre, systen, to Invo.e appropriate charging and secunty 
procedures. Instead o. having to deveiop security and charging .unctions the application 
developer and service provider need only specify appropriate policies. 

in the present invention application development is simplified by using the 
session description to drive the dynamic management of communication channels and 
„ edapt to available resources. It al.o reduces the problem o, handling charging and 

security re.ui ts ,0 a matter of specifying charging and security policies within the 

session description. 

An example of the present invention wiU now be described in detail with 
reference to the accompanying drawings, in which: 

Figure 1 is a schematic diagram illustrating a multicast transmission across the 



MBone; 



Figure 2 is a schematic diagram illustrating the distribution of an SDP 

15 announcement; 

Figure 3 is a block diagram cf a modular session description of a simple session 

generated in accordance with the present invention; 

Figure 4 is 3 block diagram of a modular session description of a complex 
session generated in accordance with the present invention; 

Figure 5 is a schematic diagram of a system for managing media stream 

connections; 

Figure 6 is a flow chart illustrating the steps involved in managing a media 
session according to the system of Figure 5; and. 

Figure 7 is a flow chart further illustrating a parsing step of Figure 6. 
25 An example of an IP multicast transmiss.on system is described with reference 

to Figure 1. Prior to a multicast transmission, an appropriate announcement containing 



20 
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a session description is made, thereby allowing end users 1 lOa-UOe ,o elect to receive 
the transmission. Each end user electing to receive the transmission Is linked to a group 
IP Multicast address 120 associated with the transmission. At the transmission time of 
the multicast session, the session streams are transm.tted from e source 130, or a 
5 plurality of sources, to the group address. A, the group address, the transmission Is 
dlssem,nated along the links 140 to those end users who have elected to receive It ,ln 

this example end users 1 10a-l 10c). 

An example of an announcement and election system is described with 
reference to F.gure 2. Most public multicast sessions are announced at a single group IP 
10 multicast address 200 dedicated to the transmission of announcements to multicast 
end users. End users 210a-210e electing to receive the announcements are linked to 
the announcement group address and, in the same way as an actual session 
transmission, each announcement arriving at the announcement group address is 
disseminated to the end users. A front end interface 220 on each end user's computer 
15 displays information obtained from the associated session description for each 
announcement. The minimum information a session description may contain is a time 
and date that the session will be active and the group IP multicast address(es) from 
which the end user may elect to receive one or more media streams and to which they 
could send their own streams for the session. Using the front end interface, an end user 
20 can select the announced session(s). or their component stream(s) they wish to 
participate in. 

Figure 3 is a block diagram of a session description 300 for. a simple multicast 
television session. The session description 300 comprises a base module 310 linked to 
a media module 320. 

25 The base module 310 contains user oriented data ■ relating to the session 

including the title and timing information. The base module 310 may also include a 
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.esc.p.o„ o, ..s„3c., con>a« .n,orma.,on a.ou, ,He o,,a.,se, and a WWW or an 
insane. UR, pCn.ng .o a «eb s.e contain.ng .u.har information. .dea„v. the base 
module 310 should contain enough information .o, the user to deoide i. they are 
interested in participating in tlie session. 
5 The media module 320 contains announcement data relating to a video stream 

o, the session. The media module 320 contains the technical information .data, 
necessary for the user to receive the associated media stream. In particular, 
connection, timing and media format details are provided. 

A first example of a session description 300 generated for transmission to end 

10 users is shown below: 



( 

typeKbase) 

id=(3l0) . „. 

•.nfo=(title="live multicast television session ) 
source={name-"A.Sender" email=asender@.tx.com) 
media=(video=(client=odbitsO. \ 6)) 
time=(length-50mrepeat=continuous) 
cate2ory=("Entenainment") 
options=(none) 
modules={m=320) 

) 



15 



( 

95 type=(n™cdia) 

id=(320 3lO) 

media=(video=(client=odbitsO. 16)) 
conneclion=(229. LI. 2/7000) 
time={length=50m) 

30 ) 



Session description example 1 

The base module 310 has a unique identifier (id field, used in the generation of 
35 lin.s between two modules during the process,ng of the session description. The 



modules 



field of the base module 310 lists the type and unique identifier of the media 
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module 320 linked to the base module 310. The second identifier in the id field of the 
media module 320 is the unique identifier belonging to the base module 310 linking the 
media module back to the base module 310. By extension, these two-way links permit 
a module tree to be traversed from a base module downwards or from a media module 
upwards. The use of this feature is described later with reference to session description 
example 4. 

The connection field of the media module 320 contains the IP multicast address 
and port number from which the media stream can be received. 

Figure 4 is a block diagram of a session description 400 for a complex multicast 
session of a multimedia conference with two tracks, or sub-sessions, and a panel 
discussion. Each track provides multiparty video and audio conferencing and a shared 
whiteboard for leaving notes and messages. The panel discussion is encrypted and the 
whole conference is subject to a subscription fee payable in advance by each 
participant. 

The session description 400 contains a top level base module 410 linked to 
further base modules 420, 430, 440 and an options module 41 1 , The top level base 
module 410 contains data relating to the overall session including its name, purpose 
and timing information. The options module 41 1 contains details of the payment 
mechanism for subscription fees. 

Each further base module 420, 430, 440 relates to a subsession of the 
conference. Base module 420 relates to the first track of the conference. The base 
module 420 is linked to media modules 421-423, each containing connection, timing 
and media format data for respective video, audio and whiteboard streams. 

The base module 420 is also linked to options module 424 which contains data 
relating to a QoS policy for the first track defining which media modules are optional 
and which are mandatory for a participant of the first track. The mandatory list contains 

0036804A1J_> 
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«e„.«e. o, .Hose n,e.l3 .oau,es .H,c. a,e neeae. ,o. ..e 3e«,on o, .u.ses.on .c 
ope.a.e co.=c„v w.U.t ..e op.ion,. con„,ns -..entmers o. ,He .eCa ™.u,es .hat 
a.a no, nacassa. for ..a sass,o„ o, su.sess.on .o opera.a co.eCv svs.a. rasou.cas 

are scarce. r i. a 

Tha basa n,oau,a 430 .ela.es .o .ha second .rac. o, .ha conference. . >,n.ad 
„ „aa. n.o.u>as 43,-433, each con..n>n. connaCon, .im>n. an. n.aa.a ,o,n,a, 
..,„s .or respeCve v«eo, au.o and wh..ehcar. s.reams. The base modu. 430 ,s 

second .rac. da„n.n, which mad,, modu,es ar. opsone, and which are manda.orv .or a 
,0 par.,cipan. o, .ha second .raC. Basa ..odu.e 440 re,a.as .o .he pane, discussion. ,s 
,in.ad .o media moduias 44. and 442, each con.ain.n, connacion, .irnin, and mad.a 
,_a. da.ai,= ,or respec.ive video and audio streams o, .ha pane, discussion. The hase 
modu,a 440 is a,so ,in.ad .o op.ions moduie 443 which con.a,ns ancrvp.ioh de.a„s „e. 
HOW and Where .o ,e. .ha nacassarv crvp.o.raph,c .avs, nacassarv for a par.,c,pan. .o 

^1. «,.»ms 441 442 accord,ng .o a known encryption 
1 5 decode the pane, discussion media streams 441 , 4» 

mechanism such as D6S or pubiic key encryption. 

media streams a„o s with dH.erent system resources to receive as much o. the 

stream as their system resources a„ows. Every user mus. reoe,ve the bottom ,aya, o. 
,0 the stream containing the minimum stream data. However, i. a user has sufficient free 
system resources .hey can receive .he nex. iayer up con.a,nin. anhancamen.s .o .he 
p,evious ,ayar. Successive ,ayers can be received anhancin. .ha race,ved madia s.raam 

,mhar of layers is received or al, free sysrem resources capaci.y is 
un.il .he maximum number ol layers is loi. 

^S on .ha ,ayarin. necessary for .he end user .o be ab,a .o receive .he iayered s.raam 
correctly- 
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The portion of the session description 400 generated for modules 410, 41 1, 420 
and 440 for transmission to end users is shown below in session description example 
2. 



( # overall conference session 
type=(base) 
id=(410) 

info=(title="Muitimedia98 Conference") 
source=(ownei^"Joe Bloggs" emaiI=joe@nowhere.com) 
media=(video=(cl!ent=RealPlayerG2) whiteboard=(client=vvb)) 
time(start-"09:00 GMT 25/12/98" stop="l3:00 GMT 25/12/98") 
options=(oc=41 1) 

modules=(b=420 b=430 b=440 oc=41 1) 

) 

( # conference track 1 
type=(base) 
id=(420 410) 

info=(tiile="MM98 Systems and Applications Track") 
source=(owner="Joe Bloggs" emai!=joe@novvhere.com) 

media=(video==(client=RsalPlayerG2) whiteboard=(ciient=vvb)) 
time(siart="09:00 GMT 25/12/98" stop='M 1:00 GMT 25/12/98") 
options=(osq=424) 

modules=(m=421 m=422 m=423 osq=424) 

) 

( # session QoS for track I 
type=(option-sQoS) 
id=(424 420) 
mandatory=(42 1 422) 
optional={^23) 



( U conference panel discussion 
type=(base) 

id=(440 410) 

info=Uitle="MM98 Panel Discussion") 
source=(namc="Joe Bloggs" eniail=joe@nowhere.com) 
media=(video=(client=RealPIayerG2) vvhiteboard={client=wb)) 
time(siart="l 1:00 GMT 25/12/98" stop="l3:00 GMT 25/12/98") 
options={osec=443) 
modules=(m=441 m=442 osec=443) 

) 

( U video for panel discussion 
type={media) 

id=(441 440) 

info=(title="MM98 Panel Discussion Video") 
source=(owner="Joe Bloggs" email=joe@nowhere.com) 
media=(video=(type=Uve client=RealPlayerG2)) 
conncction=(226.0.0. 1 06/ 1 0 ! 0 policy=444) 
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time=(start="l 1:00 GMT 25/12/98" stop- 13:00 GMT 25/12/98") 

) 

( # media QoS policy for panel discussion video 
5 type=(option-inQoS) 

m2i^ir=Oayer=(base=226.0.0.lO6/1010number=3)) 

) 

( # encryption policy for panel discussion 
type=(option-sec) 
id=(443 440) 

J g •,nfo=(location=http://w\vwAv3.org/) 
) 

( it charging policy for entire conference 
type=(option-chg) 

90 id=(4n4io) 

mechanism=Ctype=AAA) 

price=(fee=lOOOGBP) 

info=(location=http://www.aaa.netO 

^ Session description example 2 



25 



30 



Whe,s *.re is surplus netwcK bandwidth aveilable, ccn^pie, ion 

desc„p.ons can be announced .o and use. wHc .av tnen e,ect to receive the 

announced session or parts thereo,. Ho the individual n,cdu,as o, the session 

description do no, need to be announced together. „ the networ. bandwidth avaiiabie 
,or announcen^ents restricts the size session descriptions, oniv the top teve, base 
n,odu,e n,av be announced, in this situation, the iin. between n>odu,es ntav be, .or 
example, a UR, to a WWW or en intranet web site o, server, an email address, an ,P 
multicast address, an FTP address or details o. a «,e or database stored on a local 
computer system from which an interested user can obtain the remaining modules. 

The following session description example illustrates how the above sess.on 

a WWW server: 
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( ^ conference track 1 
type = (base) 
id = (420 410) 

info = (title = "MM98 Systems and Applications Track**) 
source = (owner = "Joe Bloggs" email = joe@nowhere.com) 
media = (video = (client = ReaiPlayerG2) whiteboard = (client = wb)) 
time(siart = "09:00 GMT 25/12/98" siop = "ll:00 GMT 25/12/98") 
options = (osq =424) 

modules =(m= 421 location = http://\vw\v.announce.org/cgi-bin/module,cgi?id =421 
m=421 m=423 osq=424) 

) 

Session description example 3 

Furthermore, top level modules of a session description may be announced well 
in advance of the actual transmission, at a time where the final details of content are 
unknown, in which case the remaining levels may be made available from pre- 
announced links at a later time. 

Figure 5 is a schematic diagram of a system for managing media stream 
connections at a terminal of an end user system according to the present invention. 

The session control system 500 is linked to an announcement receiving interface 
510 and one or more multicast-capable multimedia applications 520. The session 
control system 500 and the announcement receiving interface 510 are connected to a 
network interface 530 via which announcements may be received and multicast 
transmissions may be initiated and/or received. 

Announcements received at the network interface 530 are routed to the 
receiving interface 510. The receiving interface 510 decodes each announcement to 
obtain the session description and displays the user oriented information from the one 
or more base modules in a list to the user. The user is able to select a session 
description from the list announcing a session they wish to receive. The selected 
description is passed to the session control system 500 which determines which of the 
user's multimedia applications 520 are required for participation in the described 
session, starts the applications and initiates and provides the necessary media streams 
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to the respective applications 520 via a communications manager 550. 

The receiving interface 510 may be linked to other Internet communications 
applications 540 such as a WWW browser or an email client (not shown) which may be 
used to gather further information on the described session based on links provided in 
:= the session description. Also, where an incomplete set of base and/or media modules of 
a session description are received, the receiving interface 510 attempts to obtain the 
remaining modules using the Internet communications applications prior to passing it 
onto the session control system 500. 

Figure 6 is a flow chart showing the steps taken by the session control system 
10 500 upon receipt of a session description. The description is first parsed in step 600 to 
identify client applications for each media module. Once this is done a second parse is 
carried out where applications are launched in step 610, that is to say for each media 
module start the application specified in the client field if that application has not 
already been started. The portion of the session description relating to the respective 
15 media type. i.e. the media module, the base module directly above the media module, 
all other modules attached to that base module and any other options modules that 
apply, is passed to the corresponding application in step 620. Since the media modules 
are marked with appropriate client applications, each application will be able to select 
those media streams that it wants to participate in. The application replies to the 
20 session control system with a connection request specifying its requirements in the 
form of a list of identifiers of media modules from which streams are to be initiated in 
step 630. The connection request is assembled by the session control system in step 
640 and the system then parses the session description to identify other applications to 
launch in step 645. If a further media type is found, steps 610 to 640 are repeated, 
25 otherwise the session control system uses the assembled connection requests to form 
a list of media modules. This list is passed, together with a session QoS policy, to the 
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communications manager, a system used in by the session control system, which 
determines according to the QoS policies and available system resources whether each 
connection request is viable. 

The session QoS policy is constructed in two steps:- first, the multiple session 
QoS policies relevant for all the media modules to be initiated are combined into one 
session QoS policy: second, the resulting session QoS policy may be adapted to take 
account of (a) user default preferences (defined in a user profile), (b) a user's wish to 
determine the policy interactively, and (c) an application's default configuration (defined 
in the application profile(s)). 

The communications manager responds to the session control system in step 
650 with an indication of the viable media stream connection requests. If necessary, 
the session control system may contact a charging system to initiate accounting for the 
session prior to requesting the communications manager to create the viable media 
stream connections in step 660. 

Once a session starts, each received data stream relating to the session is 
passed to the associated multimedia application in step 670 until the scheduled stream 
time ends in step 680 or the multimedia application requests to the session control 
system that the connection is terminated in step 690, at which point the session 
control system disconnects the connection in step 700. 

Figure 7 is a flow chart showing the QoS management step 650 of Figure 6 in 
greater detail. 

Having received the assembled list of connection requests, the communications 
manager matches each item of this list to a media profile in step 705. A media profile 
defines requirements which must be met for the requested media stream to operate on 
the end user's computer including the minimum network bandwidth needed for 
satisfactory reception of the stream. 
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A ,e...-,n,, p,o,Ue : dete^-d ,n s.ep 7,0. THe .ec.ina, pro,.. aa«nes .he 
.sources which are avaUa«e a, ..e end user's computer for use .v the requested 
„ed,a streams. This .nCudes avaUaP.e r,etwor. bandwidth, ,ree n,emo,v and dis. space 
and avaiiahie hardware such as monitor size, processor speed and tree audio and v,deo 
5 capture devices. The media pro.iie o, each connection request is compared against the 
avaiiahie svstem resources defined Pv the termina, pro«,e ,n step 730. the tormina, 
p,o.i,e matches or exceeds the media pro.i,e, the connection request ,s deCared viaPie 

^ ^♦^H anrordinalv for the remaining 

in step 730 and the terminal profile ,s decremented accordmgly 

connection reouests in step 740. Each connection request is processed until ,h 

,0 no remaining requests or until the media profile of a reouest exceeds the terminal 

profile, in this situation, the communicat.ons manager determines the optimum terminal 

profile the user's computer would have if ai, non-essential applicafons were not runnin. 

in step 750 and whether the computer is capable of fuHiHin, the media pro.iie in step 

.ao. If the computer is capable o. fulfilling the media profile, the communications 

connection requests which have lower pricntv or bv as.n. the user to terminate other 

^♦^r% 770 Alternatively, this couid 
non-essential applications running on the computer ,n step 770. Alterna 

„ sufficient resources cannot be found an exception is reported to the u d the 

,0 connection request is marked as unviable. If the media stream that cannot be received 
is defined as mandatorv in a OoS policy for a media session or subsession, all the 
connection requests for that media sess.on o, subsession are cancelled in step 730. If, 
.p the media stream is optional, the communications manager continues 

^♦^r> 790 Once all pending connection 
processing further connection requests .n step 720. Once 

K y...n nrocessed the communications manager reports those that are 
25 requests have been processea, 

viable to the session control system. 
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The processing of a session description will now be described with reference to 
Figure 4 and session description example 4 which is the session description generated 
for Track 1 (modules 410 and 420-424 of Figure 4). 



5 { U overall conference session 

type={base) 
id=(410) 

info=(tit!e="Multimedia98 Conference") 
source=(owner="Joe Bloggs' • email=joe@nowherexom) 
1 0 mediaKvideo=(ciient=RealPlayerG2) whiteboard=(cIient=\vb)) 

time(start="09:00 GMT 25/12/98" stop=" 13:00 GMT 25/12/98") 
opiions=(oc=OOlO) 

modules=(b=420 b=430 b=440 oc=4l l) 



15 



) 



( # conference track I 
type=(base) 
id=(420 410) 

info=(title="MM98 Systems and Applications Track") 
20 source==(owner="Joe Bloggs" email=joe@nowhere,com) 

media=(video={client=RealPlayerG2) whiteboard=(client=wb)) 
time(start-"09:00 GMT 25/12/98" stop=" 1 1 :00 GMT 25/12/98") 
options=(osq=424) 

modulesKm=421 nri-422 m-423 osq=424) 

25 . ) 

( # video for track I 
iype=(media) 

id=(42 1 420) 

30 info=(title="MM98 Systems and Applications Track Video") 

source=(owner="Joe Bloggs" emaiNjoe@howhere.com) 
media=(video=(type=live client=RealPlayerG2)) 
connection-(226.0.0. 1 00/ 1 000) 

iime=(start="09:00 GMT 25/12/98" stop="l 1 :00 GMT 25/12/98") 

35 ) 

( # audio for track 1 
type=(media) 
id«(422 420) 

40 info=(title="MM98 Systems and Applications Track Audio") 

source=(ownep="Joe Bloggs" email=joe@nowhere.com) 
media=(audio=(type=!ive formar=g7 H )) 
connection-(226.0.0. 1 0 1 / 1 00 1 ) 

nme-(stan="09:00 GMT 25/12/98" stop=" 1 1 :00 GMT 25/12/98") 

45 ) 

( # whiteboard for track I 
type=(media) 
id=(423 420) 

50 info=(title="MM98 Systems and Applications Track Whiteboard") 

source=(owner="Joe Bloggs" email=joeranowhere.com) 
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media={whiteboard=(cUent=%vb)) 

) 



( # session QoS for track 1 

ty pe=(o P t'O^'SQ"^) 
id=(424 420) 
mandatory=(421 422) 

optional=(423) 

) 

Session description example 4 

processes t.e nee s™ o. t.e session description starting at .ase modu.e .10. 
T.e .rst module encountered is .ase module .20. As t.is is not a media module .ut it 

. , the session control system continues down this branch to 
does have sub-modules, the session comr 

media module. 

TH. n,edia ..eld o, .he n,e..3 .,o<,u,e 42, already de.nes ,he ™,.n,edia Cen. 
epp^cadon ,e,u.ed as Rea,P,e.e.aa .a ™uU,™d>a app«c,«cn o. Rea, NetwcKs ,nc, 

■ control system ignores it and continues to the next media module. The 

thus the session control sysiem lynw 

media «e,a o, the media module .22 does no. -i^--- -lent application 

reccnlses that this particular audio .ormat can he supported hy BealPlayer02 so ,. 
amends the media r.e,d to read client = Bea,Player02. The next media module 423 has 
already de.ned a c.len. appUcatlon as wh so it .notes this modu d it also ignores 

the option module 424. 

The session control system parses the tree structure again in order to launch 
30 Client applications. The ,lrst media module 42, specHles that .ea,P,ayer32 should he 
launched, hence th ion control system launches the application on the end user s 



25 
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application that has already been launched and so the session control system ignores it 
and continues to the next media module. The media module 423 specifies that wb 
should be launched, so the session control system launches the application and keeps a 
record of this activity. 

5 RealPlayerG2 is passed the media module 421/ base module 420 and modules 

422-424. The application processes the media modules given to determine which it can 
handle, and in this case it identifies 421 and 422. Having determined which streams it 
can handle, the application sends a connection request back to the session control 
system requesting connection to the media streams of modules 421 and 422. Similarly, 

10 wb is passed the media module 423, base module 420, modules 421-422, and the 
module 424. The application processes the given modules as described previously, and 
requests connection to the media stream of modules 423. 

The above connection requests are assembled by the session control system 
into a list, this list is then passed to the communications manager along with the 

15 session QoS policy module 424. The communications manager determines whether 
each request is viable according to the steps of Figure 7. 

Assuming there are sufficient resources for all the connection requests for 
mandatory media streams, the communications manager passes back a list of viable 
streams to the session control system which then processes the tree again to determine 

20 the connection data held in the connection field of each media module so it can request 
that the communications manager initiate a connection to the appropriate media stream 
for each of the viable connection requests according to the connection data. The 
session control system then manages the session and its media stream connections as 
is described with reference to steps 670 to 700 of Figure 6. 

25 Due to the heterogeneity of the Internet and differing capabilities and operating 

environments of end user computer systems, the session control system described has 
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• . . (Java is a Trade Mark of Sur. Microsystems Inc.). The 
beer^ implemented .n Java (Java is a 

_e.e. .ceW.. Ses..„ O.eco.. .ce.es .e anno— a„ 

.ose se,e«ea . .e en. .e. .0 .e .es.on con„o, .... ,..e.e. - 
an 3PP.c3.on p,c.— ...ace ™nn,n, as a .acK.ouna .ccess cn 

' :r 1 .esen. nas .een .esc.e. ~ . .e ,n.e,ne. 

ana n,..,cas. — ,ons, . .e .pa.n. . .e ,ea.e. .a. .e aesc*ea n,cau a 

,,,«iioahle to the announcement 
■ • o«H the session control system are applicable to tn 
session descnpfon and tne ^ ^^^^^ 

and subsequent n,anagen,ent of connections to med.a streams 
.0 using other known transport n-eonanisms such as unicast. 

furthermore, a,thou,h mechanisms ,or encrvption, charging and other such 
services ha. not heen expiiCiv descried, it wouid he apparent to the reader th^ 
appropriate session descriptions and associated .unctions within the sess,on o .0, 
system ,or their processing couid he readiW .Piemented according to the mechan.sm 
15 required. 
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CLAIMS 

1 . A method of announcing a description of a media session, comprising the steps 
of: 

5 generating a first base module having a first data structure comprising user 

oriented data relevant to the media session; 

generating at least one media module having a second data structure comprising 
media oriented data necessary for a user to receive a respective media stream of the 
media session; 

10 providing a link between the first base module and the at least one media 

module; and, 

announcing the media session by making at least the first base module available 
to potential recipients of the media session, 

wherein the link between the first base module and the at least one media 
15 module permits a user to access the at least one media module and subsequently 
receive the media stream. 

2. A method according to claim 1, further comprising the steps of: 

generating a second base module, the second base module containing user 
20 orientated data relating to a sub-session of the media session; 

linking the second base module to the first base module; and, 
linking said at least one media module to the second base module. 

3. A method according to claim 1 or 2, further comprising the steps of: 

25 generating at least one options module having a third data structure comprising 

data relating to service level criteria required to participate in the media session; and. 
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module to a respective base module. 



..im 3 in which the data contained In the options 
4. A method according to cla.m 3. 

.• h«. used bv the media session or a part 



5 thereof. 

in which the data contained in the options 

ramg - 

. ^..«i>arrk rn he US 

module relates to a se 

,hich the data contained in the 



5 A method according to claim 3 or 4, 



wr 



in 6 A method according to any of claims 3 to 5. in 

tn h« used bv the media session or a part 
options module relates to a charging system to be used by 



thereof. 



a user to receive a layered media stream of a 

,.edu,e,s, comprise data necessarv .or 

.especve meaia session; and said method .urti,er compr.ses 
eacn madia mod.e to one or more respective opt,ons mod.e.s, ' 
„ , .evered mec.anism o, ,.a respective iayered madia stream necessarv 
participate in the layered media stream. 
" . . method according to anv P— Caim, in ..C t.e data contained in a 

receive and transmit .or inclusion in the media session. 

,*.wi/-h the media session is 
.Minn to anv preceding claim, m which the me 
OS 9 A method according to any pv ^ 

nf the session descnption. 
the constituent modules ot tne se:*^!^^ 
announced by transmitting all of the cons 
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10. A method according to any of claims 1 to 8, in which the media session is 
announced by transmitting only some of the constituent modules of the session 
description, with the remaining modules of the session description being subsequently 

r accessible by a user using one or more links provided in the modules transmitted. 

11. A method according to claim 10, in which the remaining modules of the session 
description are held on one or more servers and the one or more links to the remaining 
modules are in the form of URI pointers. 

10 

12. A method according to any preceding claim, in which modules of the session 
description contain links to modules which are generated subsequent to the 
announcement. 

15 13. A computer readable storage medium containing data defining at least a part of a 
description of a media session, the session description comprising:- 

a first base module having a first data structure comprising user oriented data 
relevant to the media session; 

at least one media module having a second data structure comprising media 
20 oriented data necessary for a user to receive a respective media stream of the media 
session; 

a link between the first base module and the at least one media module; 
wherein the link permits a user to access the at least one media module and 
subsequently receive the media stream. 

25 
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